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(57) Abstract: The present invention relates to a method, system and network element for provid-ine an address transition if a 
connection point at one end of a connection is changed from a first network node to a second network node of a cellular network. An 
address information and at least one alternative address information are transmitted in a signaling message from said first network 
node to said second network node. One of said address information and said alternative address infor-mation is selected at the 
second network node and used for re-establishing said connection towards the other end of said connection. Thereby, the new point 
of connection is allowed to re-establish the connection towards the other end of the connection, even if it can only communicate 
using one of the two addresses. 
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METHOD AND SYSTEM FOR HAND OFF IN A GPRS NETWORK WITH NODES SUPPORTING 
DIFFERENT IP VERSIONS 



FIELD OF THE INVENTION 



The present invention relates to a method, system and network element for provid- 
ing an address transition, such as a transition from an IPv4 (Internet Protocol ver- 
5 sion 4) address to an IPv6 address, between a first network node and a second 
network node of a cellular network, e.g. a GPRS (General Packet Radio Services) 
network. 



BACKGROUND OF THE INVENTION 

UMTS (Universal Mobile Telecommunications System) is a more general term for 
10 the 3G (third generation) telecommunications system based on the WCDMA high 
capacity radio interface. GSM is the most widespread 2G (second generation) 
telecommunications system based on TDMA (Time Division Multiple Access) ra- 
dio. The goal of the GPRS system is to provide global layer 2 connectivity from a 
cellular mobile terminal (MT, sometimes also referred to as mobile station (MS) or • 
15 user equipment (UE)) using 2G or 3G radio technology (e.g. GSM, American 

TDMA, UMTS, GERAN (GSM/EDGE Radio Access Network) to an external packet 
data network. GPRS can support various layer 3 protocols (e.g. IPv4; IPv6; PPP 
(Point-to-Point Protocol)). 



20 The main nodes of a GPRS network are SGSN (Serving GPRS Support Node) 
and GGSN (Gateway GPRS Support Node). SGSNs are the nodes serving the 
MT. Each SGSN supports GPRS for GSM and/or UMTS. GGSNs are the node 
handling the interworking with PDNs (Packet Data Networks). Signaling and data 
are exchanged between SGSN and GGSN or SGSN and SGSN using the GTP 

25 (GPRS Tunneling Protocol) protocol. GTP protocol handles mobility, and creation, 
modification and deletion of GTP tunnels, as well as transfer of user data between 
GSNs. GTP allows multi-protocol packets to be tunneled between GSNs and be- 
tween an SGSN and the UMTS Terrestrial Radio Access Network (UTRAN, not 
shown) through which a connection to the concerned MT is established. Other 

30 systems components need not be aware of the GTP. Typically, two IP addresses 
are used for a single tunnel, one for the GTP control message (i.e. signaling) and 
one for the GTP user packet (i.e. carrying user data). 
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At GPRS attach, the SGSN establishes a mobility management (MM) context con- 
taining information pertaining to e.g. mobility and security for the concerned MT. At 
PDP context activation, the SGSN establishes a PDP context, to be used for rout- 
ing purposes, with the GGSN the subscriber will be using.A GPRS attached mo- 

5 bile terminal (MT) can be assigned either a static or dynamic IP address (referred 
to also as PDP address). The static address is assigned by the Home Public Land 
Mobile Network (HPLMN) operator at the time of subscription. The dynamic IP ad- 
dress can be allocated by a GGSN (Gateway GPRS Support Node) of either the 
HPLMN or the visited PLMN (VPLMN) operator at PDP (Packet Date Protocol) 

10 context activation time. In addition to address allocation, the GGSN implements 
the forwarding of IP packets from a GTP (GPRS Tunneling Protocol) tunnel to a 
packet data network (PDN) and vice versa. There are two kinds of PLMN back- 
bone networks, an Intra-PLMN backbone network and an Inter-PLMN backbone 
network. The Intra-PLMN backbone network is a private IP network intended for 

1 5 packet domain data and signalling within a PLMN only, while the Inter-PLMN 

backbone is used for roaming from one PLMN to another (via Border Gateways). 
Serving GPRS Support Nodes (SGSNs) and GGSNs use the Intra-PLMN back- 
bone to exchange GPRS domain data and signalling. 

20 During roaming, both the Intra-PLMN backbone of the home and visited networks 
are used in addition to the Inter-PLMN backbone. When a subscriber is roaming to 
another PLMN, i.e. a VPLMN, the user needs to first attach to the network. In 
GPRS attach, the MT informs the Serving SGSN of its intention to connect to the 
network by giving information about its identity, capability and location. The SGSN 

25 then checks the MPs identity and performs an authentication procedure in order to 
secure the transmission path. The attachment is completed after the SGSN has 
received roaming subscriber data from the Home Location Register (HLR) of the 
subscriber's HPLMN and finished a location update procedure. After the GPRS 
attach, the MT sends an 'Activate PDP context 1 request, in which the Access Point 

30 Name (APN) is a reference to the GGSN Access Point (AP) to be used in either 
the home or visited PLMN, The SGSN selects the GGSN based on a PDP context 
subscription record and sends the context data to a selected GGSN. The GGSN 
then routes the packets to the appropriate Packet Data Networks (PDN). 
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When a subscriber is roaming in the VPLMN, there are the following two possibili- 
ties for GGSN selection. Firstly, the home network GGSN can be used via the In- 
ter-PLMN backbone and BGs. The home GGSN then routes the 
5 packets to their destination. Secondly, a visited domain GGSN can be used for 
routing the packets from the VPLMN to their destination directly through a packet 
data network (PDN), such as the public Internet. 

It should be noted that there are two levels of IP addressing: 

10 

- the user IP address corresponding to the packets carried over GTP proto- 
col. The corresponding IP address is referred to as PDP address or user 
address; and 

15 - the network IP address corresponding to the packets carried below GTP 

protocol. The corresponding IP addresses are the node IP addresses used 
to exchange GTP packets between GSNs. These IP addresses might also 
be used for network operation such as charging or O&M. 

20 User and network addresses are independent of each other thanks to the GTP 
protocol, and could both be either IPv4 or IPv6. 

The GPRS backbone nodes of the second (2G) and third (3G) generation may 
optionally use an IPv6 based addressing for network addresses. However, existing 
25 specifications allowing the use of IPv6 addresses, do not define how to maintain 
backward compatibility with IPv4 based nodes. An SGSN should know in advance 
that the GGSN selected supports IPv6 addresses before inserting an IPv6 address 
e.g. in a create PDP context request message. 

30 Furthermore, another problem arises with the known procedures. If a MT moves 
from an IPv6 capable SGSN connected to an lpPv6 capable GGSN to an IPv4 
only SGSN, the communication will get lost as the new SGSN cannot use the IPv6 
address transferred. Such a scenario is very realistic in particular when two opera- 
tors with equipment from different manufacturers (or just different software re- 
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lease) have roaming agreements (e.g. national roaming). It should be noted that 
existing IPv4-to-IPv6 transition mechanisms do not apply here as they do not af- 
fect IP addresses carried in GTP. 

5 In addition, a practical requirement is that the protocol changes have to be done 
so that nodes based on older version of specifications (and so not supporting en- 
hancement proposed here), have to continue interworking with new nodes sup- 
porting the proposed enhancement proposed here. 

10 SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to provide a method and system 
for providing an address transition function, by means of which backward address 
compatibility can be achieved. 

This object is achieved by a method and system as claimed in claims 1 and 9, re- 
15 spectively. 

Additionally, the above object is achieved by a network node as claimed in claims 
11 or 13. 

Accordingly, , if one of the point of connection is changed (e.g. Inter SGSN Rout- 
ing area update; Serving RNC relocation), the old point of connection (e.g. old 
20 SGSN) shall send to the new point of connection (e.g. new SGSN) both first and 
second address, in order to allow the new point of connection to re-establish the 
connection towards the other end of the connection (GGSN), even if it can only 
communicate using one of the 2 addresses. 

Advantageous further developments are defined in the dependent claims. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

In the following, the present invention will be described in greater detail based on a 
preferred embodiment with reference to the accompanying drawings, in which: 

Fig. 1 shows a schematic block diagram of a GPRS backbone network architec- 
ture, in which the present invention can be implemented; 
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Fig. 2 shows a signaling diagram indicating indicating an Inter-SGSN routing area 
update procedure according to the preferred embodiment, and 

Fig. 3 shows a signaling diagram indicating a Serving SRNS Relocation procedure 
according to the preferred embodiment. 



DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The preferred embodiment will now be described based on a packet domain 
PLMN backbone network architecture as indicated in Fig. 1, in which an IPv6 to 
IPv4 address transition mechanism is used. 

10 According to Fig. 1 , a packet data network (PDN) 10 (e.g. an IP network) is con- 
nected via a first GGSN 31 to a first PLMN 71 comprising a first Intra-PLMN back- 
bone network 51 . Furthermore, the first PLMN 71 includes at least a first SGSN 61 
and a second SGSN 62 connected to each other and to the first GGSN 31 through 
the first Intra-PLMN backbone network 51. Additionally, the PDN 10 is connected 

15 to each other via a second GGSN 32 to a second PLMN 72 comprising a second 
Intra-PLMN backbone network 52. Furthermore, the second PLMN 72 includes at 
least a third SGSN 63 connected to the second GGSN 32 through the second In- 
tra-PLMN backbone network 52. The first and second PLMNs 71 , 71 are con- 
nected to each other via an Inter-PLMN backbone network 20. The connection 

20 between the first PLMN 71 and the Inter-PLMN backbone network 20 is provided 
through a first border gateway (BG) 41 . Similarly, the connection between the sec- 
ond PLMN 72 and the Inter-PLMN backbone network 20 is provided through a 
second BG 42. 

Each of the Intra-PLMN backbone networks 51, 52 may be a private IP network 
25 intended for packet domain data and signaling. A private IP network is an IP net- 
work to which some access control mechanism is applied in order to achieve a 
required level of security. The Inter-PLMN backbone network 20 can be packet 
data network, e.g. the public Internet or a leased line, which may be selected by a 
roaming agreement including a BG security functionality (i.e. typically just a router 
30 with security functions). The first and second BGs 41 , 42 are not defined within the 
scope of the packet domain. 
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The GPRS Support Nodes (GSNs), i.e. the first to third SGSNs 61 to 63 and the 
first and second GGSNs 31, 32, contain functionality required to support GPRS 
functionality for GSM (Global System for Mobile communication) and/or UMTS. In 
particular, the first and second GGSNs 31, 31 represent network nodes which are 
5 accessed by the PDN 10 due to evaluation of the PDP address. It contains routing 
information for GPRSattached users. The routing information is used to tunnel 
packet data units (PDUs) to the MTs current point of attachment, i.e. the respec- 
tive Serving SGSN. Thus, the first and second GGSNs 31 , 32 are the first point of 
PDN interconnection with the first and second PLMNs 71, 72, respectively. The 
10 first to third SGSNs 61 to 63 represent nodes for serving the MT. Each SGSN 
supports GPRS for GSM and/or UMTS. 

Further details regarding the network architecture and signaling procedures can be 
gathered from the 3GPP (3rd Generation Partnership Project) specification TS 
23.060 Release 4. 

15 According to the preferred embodiment, an SGSN willing to use an IPv6 address- 
ing will always indicate IPv6 and also IPv4 SGSN addresses in a respective GTP 
signaling message used to request creation of a GTP tunnel to the selected 
GGSN. Optionally, the SGSN may also indicate IPv6 and also IPv4 SGSN adr 
dresses in a respective GTP signaling message used to request update of a GTP 

20 tunnel. But this is not necessary if before sending the update, the SGSN already 
knows the type of addresses supported by GGSN. It may however be useful if the 
operator like to configure on a node by node basis the technology to be used (may 
be due to intermediate network). 

25 If the selected GGSN supports IPv6 in the network plane, it shall also indicate IPv6 
addresses in the corresponding GTP response message together with IPv4 ad- 
dresses. The IPv4 addresses are stored in the SGSN and not used for transmis- 
sion. IPv6 addresses are used for transmission on the network plane. In case of 
an inter SGSN handover, IPv4 and IPv6 addresses shall be given to the new 

30 SGSN in a backward compatible way. If the new SGSN does not support IPv6 ad- 
dresses, it uses the obtained IPv4 addresses to update the tunnel towards the 
GGSN. Also the GGSN may start receiving user data from the new SGSN before 
the tunnel has been updated. Therefore the first and second GGSNs 31, 32 shall 
be ready to receive GTP packets (signaling or user data) on either IPv4 or IPv6 

35 addresses. 
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It should be noted, that in future a new SGSN may be provided, which is capable 
of using only IPv6 on network plane, and same principles would apply. 

As an implementation alternative, the node could select the transmission technol- 
5 ogy (IPv4 or IPv6) to be used based on operator configuration 

If the selected GGSN does not support IPv6 in the network plane, it indicates only 
IPv4 addresses in the corresponding GTP response message. IPv4 addresses are 
then used for transmission on the network plane as currently defined. 

10 

Because it is proposed to send the IPv6 address as a new optional information 
element, backward compatibility can be provided so as to introduce IPv6 in future 
network nodes and maintain connections on the network plan even if a new SGSN 
supports only IPv4. 

15 In the following, examples for specific signaling messages and the incorporation of 
a specific address field for transmitting an alternative address will be described 
with reference to Figs. 2 and 3. Specific details regarding the signaling messages 
and procedures can be gathered from the 3GPP specifications TS 29,060 and TS 
23.060 Release 4. 

20 A Create PDP Context Request is sent from a SGSN node to a GGSN node as a 
part of the GPRS PDP Context Activation procedure. A valid request initiates the 
creation of a tunnel between a PDP Context in a SGSN and a PDP Context in a 
GGSN. If the SGSN prefers to use IPv6 below GTP, it include the IPv6 addresses 
in new message fields Alternative SGSN Address, and an alternative or equivalent 

25 IPv4 address in existing message fields SGSN address. If the GGSN supports 
IPv6 below GTP, it stores and uses the alternative IPv6 SGSN addresses for 
communication with the SGSN. If the GGSN supports only IPv4 below GTP, it 
stores and uses the IPv4 SGSN addresses for communication with the SGSN. The 
SGSN accepts packets whether they are sent to its IPv4 or IPv6 address. The 

30 GGSN should not store SGSN IP addresses that it does not use. This mechanism 
provides maximum flexibility, as it is not based on special DNS features, and al- 
lows the GGSN to have processes using IPv4 only and processes using both IPv4 
and IPv6. 
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The following Table 1 shows the specific information elements provided in the 
Create PDP Context Request message. 

Table 1: 



Information element 


Presence require- 
ment 


IMSI 


Conditional 


Recovery 


Optional 


Selection mode 


Conditional 


Tunnel Endpoint Identifier Data 


Mandatory 


Tunnel Endpoint Identifier Control Plane 


Conditional 


NSAPI 


Mandatory 


Linked NSAPI 


Conditional 


Charging Characteristics 


Optional 


Trace Reference 


Optional 


Trace Tvoe 


Optional 


End User Address 


Conditional 


Access Point Name 


Conditional 


Protocol Confiauration Options 


Conditional 


SGSN Address for sianallina 


Mandatory 


SGSN Address for user traffic 


Mandatory 


Alternative SGSN Address for signalling 


Optional 


Alternative SGSN Address for user traffic 


Optional 


MSISDN 


Conditional 


Quality of Sen/ice Profile 


Mandatory 


TFT 


Conditional 


Trigger Id 


Optional 


OMC Identity 


Optional 


Private Extension 


Optional 



5 The Create PDP Context Response message is sent from the GGSN node to the 
SGSN node as a response of a Create PDP Context Request. When the SGSN 



• 
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10 



15 



20 



receives the Create PDP Context Response with the Cause value indicating 'Re- 
quest Accepted', the SGSN activates the PDP context and may start to forward 
PDUs to/from the MT from/to the external data network. 

If the GGSN supports IPv6 below GTP, and the SGSN included an IPv6 SGSN 
address in the request, the GGSN shall include the IPv6 addresses in the new 
fields Alternative GGSN Address, and an equivalent IPv4 address in the fields 
GGSN address. The SGSN uses the alternative IPv6 GGSN addresses for com- 
munication with the GGSN, except if the operator has configured the use of IPv4. 
The SGSN stores the GGSN addresses and sends them to a new SGSN in a PDP 
context response message (message sent by old SGSN to new SGSN, after an 
MS has performed a Routing area update procedure to a new SGSN, that the new - 
SGSN has sent a PDP context request message to the old SGSN). The GGSN ! 
shall accept packets whether they are sent to its IPv4 or IPv6 address. This 
mechanism avoids losing connection if the new SGSN support IPv4 only below 



Table 2 shows specific information elements provided in the Create PDP Context 
Response message. 



30 
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Table 2: 



Information element 


Presence requirement 


Cause 


Mandatory 


Reordering required 


Conditional 


Recovery 


Optional 


Tunnel Endpoint Identifier Data 


Conditional 


Tunnel Endpoint Identifier Control Plane 


Conditional 


Charging ID 


Conditional 


End User Address 


Conditional 


Protocol Configuration Options 


Optional 


GGSN Address for Control Plane 


Conditional 


GGSN Address for user traffic 


Conditional 


Alternative GGSN Address for Control Plane 


Conditional 


Alternative GGSN Address for user traffic 


Conditional 


Quality of Service Profile 


Conditional 


Charging Gateway Address 


Optional 


Private Extension 


Optional 



Furthermore, an Update PDP Context Request message is sent from a SGSN to a 
GGSN as part of the GPRS Inter SGSN Routing Update procedure or the PDP 
Context Modification procedure or to redistribute contexts due to load sharing. 
The SGSN may use SGSN IPv6 addresses only if it has received an IPv6 GGSN 
1 0 address from an old SGSN (Inter SGSN Routing Area Update case) or GGSN 
(PDP context modification). Otherwise SGSN uses SGSN IPv4 addresses. 

If the GGSN supports IPv6 below GTP, and the SGSN included an IPv6 SGSN 
address in the request, the GGSN includes the IPv6 addresses in the fields Alter- 
1 5 native GGSN Address, and an equivalent IPv4 address in the fields GGSN ad- 
dress. The SGSN uses the alternative IPv6 GGSN addresses for communication 
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with the GGSN. The SGSN may store both IPv4 and IPv6 GGSN addresses and 
send them to a new SGSN in PDP context response message. The GGSN alter- 
native address fields are not sent if the GGSN address field is not sent. This 
mechanism guarantees that the SGSN always stores proper IPv4 and IPv6 GGSN 
addresses, so that connection will not be lost if moving to a new SGSN supporting 
only IPv4 below GTP. 

In the following Table 3, specific information elements in the Update PDP Context 
Response message are shown. 



Table 3: 



Information element 


Presence require- 
ment 


Cause 


Mandatory 


Recovery 


Optional 


Tunnel Endpoint Identifier Data 


Conditional 


Tunnel Endpoint Identifier Control Plane 


Conditional 


Charging ID 


Conditional 


GGSN Address for Control Plane 


Conditional 


GGSN Address for User Traffic 


Conditional 


Alternative GGSN Address for Control Plane 


Conditional 


Alternative GGSN Address for user traffic 


Conditional 


Quality of Service Profile 


Conditional 


Charging Gateway Address 


Optional 


Private Extension 


Optional 



Furthermore, as regards the SGSN Context Request message, the new SGSN 
sends this message to the old SGSN to get the mobility management (MM) and 
PDP Contexts for the MT. The old SGSN responds with an SGSN Context Re- 
sponse. 
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The new SGSN adds an SGSN Address for the control plane. If the new SGSN 
supports IPv6 below GTP, it adds its IPv6 address in the field Alternative SGSN 
Address for Control Plane. The old SGSN then selects the SGSN address for Con- 
5 trol Plane depending on its IPv6 supports, and stores this selected SGSN Address 
and uses it when sending control plane messages for the MT to the new SGSN in 
the SGSN context transfer procedure. 

Table 4 shows specific information elements provided in the SGSN Context Re- 
10 quest message. 



Table 4: 



Information element 


Presence require- 
ment 


IMSI 


Conditional 


Routeing Area Identity (RAI) 


Mandatory 


Temporary Logical Link Identifier (TLLI) 


Conditional 


Packet TMSI (P-TMSl) 


Conditional 


P-TMSI Signature 


Conditional 


MS Validated 


Optional 


Tunnel Endpoint Identifier Control Plane 


Mandatory 


SGSN Address for Control Plane 


Mandatory 


Alternative SGSN Address for Control 
Plane 


Conditional 


Private Extension 


Optional 



The old SGSN sends an SGSN Context Response message to the new SGSN as 
1 5 a response to a previous SGSN Context Request. The old SGSN may use SGSN 
IPv6 addresses only if it received IPv6 SGSN address from the new SGSN. Oth- 
erwise SGSN shall use SGSN IPv4 addresses. 
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The new SGSN sends an SGSN Context Acknowledge message to the old SGSN 
as a response to the SGSN Context Response message. Only after receiving the 
SGSN Context Acknowledge message, the old SGSN starts to forward user data 
packets. SGSN Context Acknowledge indicates to the old SGSN that the new 
5 SGSN has correctly received PDP Context information and is ready to receive 
user data packets. 

The new SGSN uses an SGSN Address for user traffic, which may differ from that 
provided by the underlying network service (e.g. IP). The old SGSN stores this 
10 SGSN Address and uses it when sending downlink PDUs to the new SGSN for the 
MT. The SGSN may use IPv6 addresses only if it received IPv6 SGSN address 
for control plane from the old SGSN. Otherwise the SGSN use SGSN IPv4 ad- 
dresses. 

15 Fig. 2 shows a signaling diagram indicating an Inter-SGSN routing area update 
procedure according to the preferred embodiment. 

In this signaling example, the MT sends a Routing Area Update Request to a new 
SGSN, so as to initiate a routing area update. In response thereto, the new SGSN 

20 sends an SGSN Context Request message including the SGSN Address fields 
and the Alternative SGSN Address fields to the old SGSN. In response thereto, 
the old SGSN returns an SGSN Context Response message in which the desired 
address type is set in the SGSN Address for Control Plane fields, and all GGSN 
IPv4 and IPv6 addresses are included if available. The new SGSN responds with 

25 an SGSN Context Acknowledge message including the used address type infor- 
mation. Then, the new SGSN sends an Update PDP Context Request message 
including the set address type information to the respective GGSN. This message 
is sent using a GGSN IP address received from old SGSN. If the new SGSN and 
GGSN support IPv6 on the network plane, the IPv6 address of GGSN is preferably 

30 used. If either SGSN or GGSN does not support IPv6, IPv4 addresses are used. 
Here, it is assumed that in a first phase of transition towards IPv6, all nodes sup- 
port IPv4. The GGSN returns an Update PDP Context Response message includ- 
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ing the GGSN Address fields and the Alternative GGSN Address fields. These ad- 
dress fields are especially necessary in the following cases: 

- The old SGSN supported only IPv4, and had not stored the alternative 

5 GGSN address, so that the new SGSN needs to receive it from GGSN to 

be able to use IPv6 for the connection 

- The GGSN has changed its IP address (typically due to a reallocation of the 
PDP context to a new processing card) 

10 

In addition, if for some reason, the GGSN is configured to use IPv4 to communi- 
cate towards the new SGSN (due to possible problem in intermediate IP network), 
the GGSN will return only the IPv4 addresses and will not send an alternative ad- 
dress field containing the IPv6 address. 

15 

Finally, the required routing area update procedure is performed. 

As a further GTP signaling message, a Forward Relocation Request message is 
defined, which is sent by an old SGSN to a new SGSN to convey necessary in- 

20 formation to perform an SRNS (Serving Radio Network Subsystem) relocation 
procedure between the new SGSN and a target RNC (Radio Network Controller) 
of the UTRAN. In this case, the old SGSN adds an SGSN Address for Control 
Plane field information. If the old SGSN supports IPv6 below GTP, it adds its IPv6 
address in this field Alternative SGSN Address for Control Plane. The new SGSN 

25 selects the SGSN address for Control Plane depending on its IPv6 supports, and 
stores this selected SGSN address and uses it when sending control plane mes- 
sages for the MT to the old SGSN in the SRNS relocation procedure. 

Table 5 shows specific information elements provided in the Forward Relocation 
30 Request message. 
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Table 5: 



Information element 


Presence requirement 


IMSI 


Mandatory 


Tunnel Endpoint Identifier Control Plane 


Mandatory 


RANAP Cause 


Mandatory 


MM Context 


Mandatory 


PDP Context 


Conditional 


SGSN Address for Control plane 


Mandatory 


Alternative SGSN Address for Control plane 


Optional 


Target Identification 


Mandatory 


UTRAN transparent container 


Mandatory 


Private Extension 


Optional 



The new SGSN sends a Forward Relocation Response message to the old SGSN 
5 as a response to a previous Forward Relocation Request message. The new 
SGSN adds an SGSN Address for Control Plane information. The SGSN may 
insert IPv6 addresses only if it received an IPv6 SGSN address for control plane 
from the old SGSN. Otherwise the new SGSN uses SGSN IPv4 addresses. The 
old SGSN stores this SGSN address and uses it when sending control plane mes- 
10 sages for the MT to the new SGSN in the SRNS relocation procedure. 

Fig. 3 shows a signaling diagram indicating an SRNS (Serving Radio Network 
Subsystem) relocation procedure according to the preferred embodiment. 

In this signaling example, a source SRNS of the UTRAN decides to perform or 
15 initiate an SRNS relocation and sends a Relocation Required message to the old 
SGSN. In response thereto, the old SGSN determines if the SRNS relocation is an 
inter-SGSN SRNS relocation and, if so, it sends a Forward Relocation Request 
message including the SGSN Address field and the Alternative SGSN Address 
field for control plane signaling to the respective new SGSN. In response thereto, 
20 the new SGSN send a Relocation Request message to the target Radio Network 
Controller (RNC) of the UTRAN. Then, the lu bearers of the radio access bearers 
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(RABs) are setup between the target RNC and the new SGSN as the existing ra- 
dio bearers will be reallocated between the MT and the target RNC when the tar- 
get RNC takes the role of the Serving RNC in the new SRNS. After the new SGSN 
has received the Relocation Request Acknowledgement message from the 

5 UTRAN, the GTP tunnels are established between the target RNC and the new 
SGSN. Then, the Forward Relocation Response message is sent from the new 
SGSN to the old SGSN to thereby indicate that the target RNC is ready to receive 
from the source SRNC (Serving RNC) of the SRNS the forwarded packet data 
units (PDUs). The old SGSN continues the SRNS relocation by sending a Reloca- 

10 tion Command message to the source SRNC. The source SRNC is now ready to 
forward downlink user data directly to the target RNC. When the data forwarding is 
completed, the target RNC send a relocation Detect message to the new SGSN. 
In response thereto, the new SGSN sends an Update PDP Context Request mes- . 
sage to a concerned GGSN. The GGSN returns an Update PDP Context Re- 

15 sponse message including the GGSN Address fields and the Alternative GGSN 
Address fields. When the new SGSN receives a Relocation Complete message 
from the SRNC, a Forward Relocation Complete signaling is exchanged between 
the new and the old SGSNs , and then the old SGSN initiates an lu release proce- 
dure at the SRNC. Finally, if the new Routing Area Identification is different, the 

20 MT initiates a Routing Area Update procedure. 

Furthermore, a PDP Context information element contains the Session Manage- 
ment parameters, defined for an external packet data network address, that are 
necessary to transfer between SGSNs at the Inter SGSN Routing Area Update 
25 procedure. 

If the GGSN negotiated the use of IPv6 below GTP with the old SGSN, the old 
SGSN sets Alternative GGSN Address for User Traffic and Alternative GGSN Ad- 
dress for Control Plane fields to contain the IPv6 addresses to be used to 
30 communicate with the GGSN. A new SGSN not supporting IPv6 below GTP 
ignores these alternative GGSN addresses, and uses for communication the 
GGSN Address for User Traffic and GGSN Address for Control Plane fields. A 
new SGSN supporting IPv6 below GTP stores the GGSN Address for User Traffic 
and GGSN Address for Control Plane, but uses use for communication the 
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Control Plane, but uses use for communication the Alternative GGSN Address for 
User Traffic and Alternative GGSN Address for Control Plane. 



In Table 6, a PDP Context information field is shown. 



5 
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Table 6 



1 

2-3 
4 



Type = 130 (Decimal) 



Length 



Res- 
erved 



VAA 



Res- 
erved 



Order 



NSAPI 



SAPI 



6 


QoS Sub Length 


7-(q+6) 


QoS Sub [4..2S5] 


Q+7 


QoS Req Length 


(q+8M2q+7) 


QoS Req [4..255J 


2q+8 


QoS Neg. Length 


(2q+9H3q+8) 


QoS Neg [4..2S5] 


(3q+9H3q+10) 


Sequence Number Down (SND) v 


(3q+11>- 


Sequence Number Up (SNU) 11 


(3q+12) 




3q+13 


Send N-PDU Number ,J 


3q+14 


Receive N-PDU Number 1; 


(3q+15)- 


Uplink Tunnel Endpoint Identifier Control Plane 


(3q+18) 




(3q+19)- 


UplinkTunnel Endpoint Identifier Data 1 


(3q+22) 




3q+23 


PDP Context Identifier 


3q+24 


Spare 1111 jPDP Type Organisation 


3q+25 


PDP Type Number 


3q+26 


PDP Address Length 


(oq+Zf y-m 


PDr Address p ..ooj 


M+1 


GGSN Address for control plane Length 


(m+2)-n 


GGSN Address for control plane [4. .16] 


N+1 


GGSN Address for User Traffic Length 


(n+2)-o 


GGSN Address for User Traffic [4..16] 


0+1 


APN length 


<o+2)-p 


APN 


P+1 


Spare (sent as 0 0 0 0) jTransaction Identifier 


P+2 


Transaction Identifier 




Alternative GGSN Address for control plane Length 




Alternative GGSN Address for control plane [4..16] 




Alternative GGSN Address for User Traffic Length 




Alternative GGSN Address for User Traffic [4..16] 
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It is noted that the present invention can be implemented in any cellular network to 
provide address or network backward compatibility, when an address information 
5 is transferred between network nodes. The names of the various functional enti- 
ties, signaling messages and information elements used in the context of the pre- 
ferred embodiment are not intended to limit or restrict the invention. The preferred 
embodiments may thus vary within the scope of the attached claims. 
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Claims 



5 
10 

2. 

15 

3. 

20 

4. 

25 

5. 



A method for providing an address or network transition if a connection 
point at one end of a connection is changed from a first network node to a 
second network node of a cellular network, said method comprising the 
steps of: 

a) transmitting an address information and at least one alternative address 
information in a signaling message from said first network node to said 
second network node; 

b) selecting one of said address information and said alternative address 
information at said second network node; and 

c) using said selected address information for re-establishing said connec- 
tion towards a third node at the other end of said connection. 

A method according to claim 1 , wherein, when establishing said connec- 
tion, possible addresses to be used for this connection are transmitted as 
said address information and said at least one alternative address informa- 
tion in a signaling message from said first network node to said third net- 
work node, and addresses of said third node are stored in said first network 



A method according to claim 1 or 2, where said address information can be 
used to address a node according to an old addressing or network, used 
before the transition, and said alternative address information can be used 
to address a node according to the new addressing or network. 

A method according to any one of the preceding claims, wherein said sig- 
naling message is sent as part of a location or routing area update mes- 
sage or a relocation procedure. 

A method according to any one of the preceding claims, wherein said sig- 
naling message is a GTP message. 



6. 

30 



A method according to any one of the preceding claims, wherein said first 
and second network nodes are SGSNs, and said third network node is a 
GGSN. 
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7. A method according to any one of the preceding claims, wherein said ad- 
dress information and said alternative address information are a user and/or 
network addresses. 

8. A method according to claim 7, wherein said address information and said 
5 alternative address information are IPv4 or IPv6 addresses. 

9. A method according to any one of the preceding claims, wherein said ad- 
dress information and said alternative address information are transmitted 
in respective predetermined fields of said signaling message. 

10. A method according to claim 9, wherein said predetermined fields are pro- 
10 vided in a PDP context information field. 

11. A method according to any one of the preceding claims, wherein said alter- 
native address information is coded as an optional information so that a 
network node not supporting said alternative address information ignores it. 

12. A method according to claim 1 1 , wherein said connection is re-established 
15 with an old addressing mechanism based on said address information if 

said second node ignores said alternative address information. 

13. A system for providing an address or network transition, said system com- 
prising: 

a) a first network node for transmitting an address information and at least 
20 one alternative address information in a signaling message if a connec- 
tion point at one end of a connection is changed from said first network 
node; and 

b) a second network node for receiving said signaling message if said con- 
nection point is changed to said second network node, for selecting one 

25 of said address information and said alternative address information, 

and for using said selected address information for re-establishing said 
connection towards a third network node at the other end of said con- 
nection. 



30 14. 



A system according to claim 13, wherein said first and second network 
nodes are SGSNs of a GPRS backbone network, and wherein said third 
network node is a GGSN of said GPRS backbone network. 
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15. A network node of a cellular network, said network node being arranged to 
transmit an address information and at least one alternative address infor- 
mation in a signaling message, if a connection point at one end of a con- 

5 nection is changed from said network node to another network node. 

16. A network node according to claim 15, where said transmitted address in- 
formation and said at least one alternative address information is used to 
reestablish said connection towards a third node. 

17. A network node according to claim 16, wherein said network node is 

10 adapted to store said address information and said alternative address in- 

formation in order to be used to address said third network node. 

18. A network node according to any one of claims 15 to 17, wherein said net- 
work node is an SGSN. 

19. A network node of a cellular network, said network node being arranged to 
1 5 receive a signaling message if a connection point at one end of a connec- 
tion is changed from another network node to said network node, to select 
one of an address information and an alternative address information pro- 
vided in said signaling message, and to use said selected address informa- 
tion for re-establishing said connection towards a third network node at the 

20 other end of said connection. 

20. A network node according to claim 19, wherein said network node is 
adapted to receive data and/or signaling either on said address information 
or on said alternative address information. 



21. 

25 



A network node according to claim 19 or 20, wherein said network node is a 
GGSN. 
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